home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0068.001 < prev    next >
Text File  |  1992-12-13  |  12KB  |  306 lines
  1. Document: FSC-0068
  2. Version:  001
  3. Date:     13-Dec-1992
  4.  
  5.  
  6.  
  7.  
  8.                       A Proposed Replacement For FTS-0004
  9.  
  10.                                   Mark Kimes
  11.                                1:380/16@fidonet
  12.     
  13.  
  14.  
  15.  
  16. Status of this document:
  17.  
  18.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  19.      and requests discussion and suggestions for improvements.
  20.      Distribution of this document is unlimited.
  21.  
  22.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  23.      Software.
  24.  
  25.  
  26.  
  27.  
  28. Echomail documentation:
  29. ======================
  30.  
  31.  
  32.  
  33. Definition:
  34. ==========
  35. Echomail, sometimes called broadcast or conference mail, is netmail
  36. (ref. FTS-0001) containing additional control information that allows it
  37. to be "echoed" (forwarded) from node (site) to node.  Echomail is
  38. divided into areas, or conferences, with unique names.
  39.  
  40. The format for packets, message headers and message text is identical to
  41. that specified for netmail in FTS-0001.
  42.  
  43.  
  44.  
  45. Control lines in general:
  46. ========================
  47. A control line is a line of text in the message's body (the
  48. nul-terminated text portion of a message following the binary header;
  49. see FTS-0001) ended by a carriage return. Some control lines are
  50. preceded by a ^a (control-a, ASCII character 1) and are sometimes
  51. referred to as "kludge lines."  Kludge lines are normally not shown when
  52. displaying a message; the reading software will treat the initial ^a as
  53. meaning "not (normally) for human consumption."
  54.  
  55.  
  56.  
  57. Required control information:
  58. ============================
  59. AREA:  An AREA tag is what makes the difference between netmail and
  60. echomail.  The AREA line must be the first line in an echomail message's
  61. body.  An AREA line's format is simply:
  62.  
  63. AREA:<areaname>
  64.  
  65. The AREA tag is specifically _not_ preceded by a ^a.  It might be a good
  66. idea for an application to allow for but not produce AREA tags with ^a
  67. prefixes.
  68.  
  69. Where <areaname> is the unique name of the echomail conference.  For
  70. compatibility with existing software, area names should not begin with
  71. the plus or minus ("+" or "-") symbols.  Area names must not contain
  72. control characters (less than ASCII character 32, a space).  Leading
  73. and trailing spaces on the area name should be ignored (and preferably
  74. not produced).  Compares on the area name should be case insensitive.
  75.  
  76. Area names are generally kept as short as possible while still
  77. maintaining uniqueness and some sense of what the area's topic is about.
  78.  
  79.  
  80. The purpose of the SEEN-BY control line is to protect fully connected
  81. polygon topology (see Topology below) from duplicate message looping.
  82. Keeping SEEN-BYs beyond a small topology group is wasteful and should be
  83. avoided, but a message must contain at least "Tiny Seenbys" in order to
  84. avoid choking older mail processors.  Tiny Seenbys are the node
  85. currently processing the message and any nodes to which that node is
  86. sending the message.  This means that in all cases a SEEN-BY line will
  87. contain more than one address.
  88.  
  89. SEEN-BYs are located after any Origin line and before any PATH line(s).
  90.  
  91. A SEEN-BY line has the following format:
  92.  
  93. SEEN-BY <net/node> <[net]/node> ... <[net]/node>
  94.  
  95. The 2-D addresses following the SEEN-BY tag are "net sticky," which
  96. means that net information is not duplicated if unchanged from the
  97. previous address listed.  For example, if 380/20 sends a message to
  98. 380/16, 380/100 and 170/1, the SEEN-BY line would read:
  99.  
  100. SEEN-BY 170/1 380/16 20 100
  101.  
  102. SEEN-BY tags are specifically _not_ preceded by ^a.  It might be a good
  103. idea for applications to allow for but not produce SEEN-BY tags with ^a
  104. prefixes.
  105.  
  106. SEEN-BY addresses _are_ specifically sorted by net/node.  It might be a
  107. good idea for applications to allow for but not produce unsorted SEEN-BY
  108. addresses.
  109.  
  110. SEEN-BY lines should not exceed 79 bytes in length; if more addresses
  111. are required than can be represented on one line, a carriage return
  112. followed by another SEEN-BY tag followed by more addresses should be
  113. added.
  114.  
  115. Current practice is to strip SEEN-BYs at zone and domain gates since
  116. their 2-D nature make them useless for duplicate message checking beyond
  117. a given zone.
  118.  
  119.  
  120.  
  121. Optional control information:
  122. ============================
  123. Origin:  Origin lines, when they appear, contain the text " * Origin: "
  124. at the start of the line, and an address in parentheses at the end of
  125. the line.  Between these two portions of the line there may be some
  126. other text which can be ignored.  Origin lines may contain addresses in
  127. many formats, from simple 2-D net/node to 5-D domain addresses.
  128.  
  129. An echomail processor should never choke because a message contains no
  130. Origin.
  131.  
  132. Origin lines are specifically _not_ preceded by ^a, and should be no
  133. longer than 79 characters in total length.
  134.  
  135. Some existing mail processors may choke on echomail that does not
  136. contain an origin line.  Therefore, for maximum compatibility, echomail
  137. processors should have an option, perhaps on a conference-by-conference
  138. basis, to assure all messages originating at a site contain an Origin
  139. (adding a default one if not already present).  In situations where an
  140. Origin is not used, a MSGID (see below) should be used so that private
  141. (netmail) replies are possible.
  142.  
  143. Some gateways add their own Origin line and change any existing Origin
  144. line to " # Origin: <rest of original origin>".  You should keep this in
  145. mind if attempting to use Origin lines to find the "real" origin of a
  146. message.
  147.  
  148.  
  149. PATH:  PATH line(s), when they appear, follow the message's SEEN-BY
  150. line(s).  PATH lines are specifically preceded by ^a, and should be no
  151. longer than 79 characters in length.
  152.  
  153. PATH lines have only one purpose:  to convey to a human some information
  154. about which systems have processed (forwarded) a message, and in what
  155. order.  The 2-D (net/node) nature of PATH coupled with the practice of
  156. not stripping PATH lines from a message at zone gates make it impossible
  157. to reliably use for the prevention of duplicate message looping (you
  158. can't tell if 380/16 refers to 1:380/16 or 2:380/16, or
  159. Dufusnet#1:380/16 instead of Fidonet#1:380/16).
  160.  
  161. A PATH line has the following format:
  162.  
  163. ^aPATH <net/node> <[net]/node> ... <[net]/node>
  164.  
  165. Like SEEN-BYs, PATH lines consist of a tag, ^aPATH, followed by 2-D "net
  166. sticky" addresses.  Unlike SEEN-BYs, PATH is specifically _not_ sorted,
  167. and it's possible there will be only one address.  For example, assuming
  168. all nodes support PATH, given that a message originates on 380/16, and
  169. goes through 380/20 to 380/100, the PATH line at 380/100 would read:
  170.  
  171. ^aPATH 380/16 20
  172.  
  173. and the PATH line at 380/20 would read simply:
  174.  
  175. ^aPATH 380/16
  176.  
  177.  
  178.  
  179. Other optional information:
  180. ==========================
  181. Tear line:  A tear line, when it appears, consists of three dashes
  182. ("---") at the beginning of a line, sometimes followed by a space and
  183. some text, possibly the name of the editor, packer, or BBS that created
  184. or first manipulated the message.  Tear lines, when present, are located
  185. just before the Origin line.
  186.  
  187. Tear lines serve no control purpose, but are often placed into messages
  188. for historical reasons.  They should be considered as what they are:
  189. just part of the message text.
  190.  
  191.  
  192. MSGID:  A control line defined in FTS-0009.  Identifies the origin
  193. address of the message, and provides a unique serial number that can be
  194. used for linking replies and duplicate message control.
  195.  
  196.  
  197. REPLY:  A control line defined in FTS-0009.  In conjunction with MSGID,
  198. can be used to link replies to original messages.
  199.  
  200.  
  201. INTL, TOPT:  Netmail routing control lines defined in FTS-0001.  These
  202. control lines should not appear in echomail as they impart "false"
  203. information after the first "stop" due to the nature of echomail.
  204.  
  205.  
  206. FMPT:  A control line defined in FTS-0001.  Identifies point portion of
  207. from address.  This control line should not appear in echomail unless
  208. there is no MSGID and the Origin line doesn't list the point portion of
  209. the address.
  210.  
  211.  
  212. You may find other (experimental) kludge lines in an echomail message.
  213. Generally speaking, a kludge which is "netmail only," like a routing
  214. kludge or a "VIA" line, should not appear in echomail.  Remember that
  215. the cost of transmitting a message will be borne by many nodes, and
  216. extraneous, unuseful information produces unnecessary additional cost.
  217. All control information in echomail messages should be kept as small as
  218. possible.
  219.  
  220. If you're curious about the uses of an experimental kludge and/or are
  221. considering supporting it, check for an FSC-* document covering it.
  222.  
  223.  
  224.  
  225. Security considerations:
  226. =======================
  227. Echomail processors that attempt to provide a "secure" environment
  228. should not rely on the message header address, but use the packet header
  229. address (and possibly the password field) instead.  The packet header
  230. field will reflect who sent you the message.  Message header addresses
  231. are usually also changed to reflect the forwarder instead of the "real"
  232. origin, but this is not guaranteed (and perhaps not even desirable).  To
  233. find the "real" origin of a message, check for a MSGID and/or Origin
  234. line.
  235.  
  236.  
  237.  
  238. Topology considerations:
  239. =======================
  240. Nothing creates duplicate message loops faster than bad topology.
  241. Consider the following simple diagram:
  242.  
  243.                 B<---->C
  244.                 ^      ^
  245.      A<-------->|      |<-------->F
  246.                 v      v
  247.                 D<---->E
  248.  
  249. This topology contains a duplicate message loop.  Consider:  B receives
  250. mail from A and forwards to C, D and F.  C, D and F forward to E.  If we
  251. connect the polygon so:
  252.  
  253.                 B<---->C
  254.                 ^\    /^
  255.      A<-------->|  \/  |<-------->F
  256.                 v /  \ v
  257.                 D<---->E
  258.  
  259. In this topology (fully connected polygon), no such duplicate message
  260. sending occurs.  While fully connected polygons can be effective in some
  261. networks (these are the reason SEEN-BYs can be necessary for more than
  262. backward compatibility), a better topology in general is the star and/or
  263. tree:
  264.  
  265.                                              +<-->E
  266.                                              ^
  267.                                              |
  268.                                              v
  269.             another tree           +<-->D<-->+<-->F
  270.                   ^                ^         ^
  271.                   |                |         |
  272.                   |                |         v
  273.                   v                v         +<-->G
  274. another tree <--->A<--------->B<-->+
  275.                   ^                ^         +<-->H
  276.                   |                |         ^
  277.                   |                |         |
  278.                   v                v         v
  279.             another tree           +<-->C<-->+<-->I
  280.                                              ^
  281.                                              |
  282.                                              v
  283.                                              +<-->J
  284.  
  285. Echomail topology should be carefully monitored by the systems involved
  286. to prevent formation (or quickly disassemble) costly duplicate message
  287. looping constructs.
  288.  
  289.  
  290.  
  291. Acknowledgements:
  292. ================
  293. Tom Jennings "created" Fidonet.  Jeff Rush "created" echomail.  Bob
  294. Hartman's ConfMail docs served as the echomail specification for years,
  295. and did so admirably; the mail moved.
  296.  
  297.  
  298.  
  299. Related documents:
  300. =================
  301. FTS-0001            (transport layer, packet format, various kludge lines)
  302. FTS-0009            (MSGID and REPLY)
  303. FSC-0039            (alternate packet header format)
  304. FSC-0043            (hints on recognizing control information)
  305. FSC-0045            (alternate packet header format)
  306.